-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add/move tests for Vc generics #8843
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
8 Skipped Deployments
|
This stack of pull requests is managed by Graphite. Learn more about stacking. |
🟢 Turbopack Benchmark CI successful 🟢Thanks |
✅ This change can build |
|
// Test that we can convert a `Vc` to a `ReadRef`, and then back to a `Vc`. | ||
#[tokio::test] | ||
#[ignore = "TODO: This panics! There's a casting bug in the generics implementation."] | ||
async fn test_read_ref_round_trip() { | ||
run(®ISTRATION, async move { | ||
let c: Vc<Option<Vc<u8>>> = Vc::cell(Some(Vc::cell(1))); | ||
let _ = ReadRef::cell(c.await.unwrap()).await.unwrap(); | ||
}) | ||
.await | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This panics due to a bug in the current generics implementation. Fixed in #8845
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The plan (as of yesterday) is to remove support for generics, but I'd feel more confident if I can fix the casting issues in my local Vc PRs before I do that.
Mind elaborating a little about removing generics?
Any other reviewers feel free to approve I just want to leave this open so I can close the loop and come back to it.
We discussed this during office hours, and decided that:
So the agreement in the room between @sokra, @ForsakenHarmony, @wbinnssmith, and myself was that it's just not worth it, and we should remove it. |
03dd222
to
7319604
Compare
## Description Fixes the test case introduced in #8843. The theory is that Vcs are supposed to be stored as `<<T as VcValueType>::Read as VcRead<T>>::Repr`. However, it looks like due to an oversight, `ReadRef::cell` is trying to store the value as `T`. This introduces a way to perform ## Testing Instructions ``` cargo nextest r -p turbo-tasks -p turbo-tasks-memory ```
## Description - Move the tests out of `all_in_one` so that we can see exactly which parts are failing more easily. - Add a few more tests. **The newly added `test_read_ref_round_trip` fails** (and is ignored), indicating a bug in the generics implementation!!! This is fixed in #8845. ## Why does `test_read_ref_round_trip` fail? The theory is that Vcs are supposed to be stored as `<<T as VcValueType>::Read as VcRead<T>>::Repr`. However, it looks like due to an oversight, `ReadRef::cell` is trying to store the value as `T`. ## Why add these tests at all? The plan (as of yesterday) is to remove support for generics, but I'd feel more confident if I can fix the casting issues in my local Vc PRs before I do that. These tests should help me understand what's happening and debug things. ## Testing Instructions ``` cargo nextest r -p turbo-tasks -p turbo-tasks-memory ```
## Description - Move the tests out of `all_in_one` so that we can see exactly which parts are failing more easily. - Add a few more tests. **The newly added `test_read_ref_round_trip` fails** (and is ignored), indicating a bug in the generics implementation!!! This is fixed in #8845. ## Why does `test_read_ref_round_trip` fail? The theory is that Vcs are supposed to be stored as `<<T as VcValueType>::Read as VcRead<T>>::Repr`. However, it looks like due to an oversight, `ReadRef::cell` is trying to store the value as `T`. ## Why add these tests at all? The plan (as of yesterday) is to remove support for generics, but I'd feel more confident if I can fix the casting issues in my local Vc PRs before I do that. These tests should help me understand what's happening and debug things. ## Testing Instructions ``` cargo nextest r -p turbo-tasks -p turbo-tasks-memory ```
…70815) Removes the uses of generic vc collections in `next-core/src/app_structure.rs` and it's callsites. ## Why? Rather than extended support for `Vc` generics to `ResolvedVc`, I plan to remove support for them entirely. That means fixing all the callsites (there's not many). Removing this is needed to get us to a point where 100% of structs can be `ResolvedValue`, because structs using these fields cannot otherwise be ported over to `ResolvedVc`. ## Okay, but Why? Explained here: vercel/turborepo#8843 (comment) I expect removing support for this will decrease the overall size of the codebase, as the logic for supporting generics is rather complicated.
…rics in non-test code (#70816) After this change, `cargo check` on a branch that deletes vc generics support compiles successfully. ## Why? Rather than extended support for `Vc` generics to `ResolvedVc`, I plan to remove support for them entirely. That means fixing all the callsites (there's not many). Removing this is needed to get us to a point where 100% of structs can be `ResolvedValue`, because structs using these fields cannot otherwise be ported over to `ResolvedVc`. ## Okay, but Why? Explained here: vercel/turborepo#8843 (comment) I expect removing support for this will decrease the overall size of the codebase, as the logic for supporting generics is rather complicated.
The previous PRs in this stack remove the only uses/callsites. This removes support for vc generics! There's still a small bit of support left in the form of `VcValueType::Repr`, but that touches more things, so that'll be a follow-up PR. ## Why? Rather than extended support for `Vc` generics to `ResolvedVc`, I plan to remove support for them entirely. That means fixing all the callsites (there's not many). Removing this is needed to get us to a point where 100% of structs can be `ResolvedValue`, because structs using these fields cannot otherwise be ported over to `ResolvedVc`. ## Okay, but Why? Explained here: vercel/turborepo#8843 (comment) I expect removing support for this will decrease the overall size of the codebase, as the logic for supporting generics is rather complicated.
…70815) Removes the uses of generic vc collections in `next-core/src/app_structure.rs` and it's callsites. ## Why? Rather than extended support for `Vc` generics to `ResolvedVc`, I plan to remove support for them entirely. That means fixing all the callsites (there's not many). Removing this is needed to get us to a point where 100% of structs can be `ResolvedValue`, because structs using these fields cannot otherwise be ported over to `ResolvedVc`. ## Okay, but Why? Explained here: vercel/turborepo#8843 (comment) I expect removing support for this will decrease the overall size of the codebase, as the logic for supporting generics is rather complicated.
…rics in non-test code (#70816) After this change, `cargo check` on a branch that deletes vc generics support compiles successfully. ## Why? Rather than extended support for `Vc` generics to `ResolvedVc`, I plan to remove support for them entirely. That means fixing all the callsites (there's not many). Removing this is needed to get us to a point where 100% of structs can be `ResolvedValue`, because structs using these fields cannot otherwise be ported over to `ResolvedVc`. ## Okay, but Why? Explained here: vercel/turborepo#8843 (comment) I expect removing support for this will decrease the overall size of the codebase, as the logic for supporting generics is rather complicated.
The previous PRs in this stack remove the only uses/callsites. This removes support for vc generics! There's still a small bit of support left in the form of `VcValueType::Repr`, but that touches more things, so that'll be a follow-up PR. ## Why? Rather than extended support for `Vc` generics to `ResolvedVc`, I plan to remove support for them entirely. That means fixing all the callsites (there's not many). Removing this is needed to get us to a point where 100% of structs can be `ResolvedValue`, because structs using these fields cannot otherwise be ported over to `ResolvedVc`. ## Okay, but Why? Explained here: vercel/turborepo#8843 (comment) I expect removing support for this will decrease the overall size of the codebase, as the logic for supporting generics is rather complicated.
…70815) Removes the uses of generic vc collections in `next-core/src/app_structure.rs` and it's callsites. ## Why? Rather than extended support for `Vc` generics to `ResolvedVc`, I plan to remove support for them entirely. That means fixing all the callsites (there's not many). Removing this is needed to get us to a point where 100% of structs can be `ResolvedValue`, because structs using these fields cannot otherwise be ported over to `ResolvedVc`. ## Okay, but Why? Explained here: vercel/turborepo#8843 (comment) I expect removing support for this will decrease the overall size of the codebase, as the logic for supporting generics is rather complicated.
…rics in non-test code (#70816) After this change, `cargo check` on a branch that deletes vc generics support compiles successfully. ## Why? Rather than extended support for `Vc` generics to `ResolvedVc`, I plan to remove support for them entirely. That means fixing all the callsites (there's not many). Removing this is needed to get us to a point where 100% of structs can be `ResolvedValue`, because structs using these fields cannot otherwise be ported over to `ResolvedVc`. ## Okay, but Why? Explained here: vercel/turborepo#8843 (comment) I expect removing support for this will decrease the overall size of the codebase, as the logic for supporting generics is rather complicated.
The previous PRs in this stack remove the only uses/callsites. This removes support for vc generics! There's still a small bit of support left in the form of `VcValueType::Repr`, but that touches more things, so that'll be a follow-up PR. ## Why? Rather than extended support for `Vc` generics to `ResolvedVc`, I plan to remove support for them entirely. That means fixing all the callsites (there's not many). Removing this is needed to get us to a point where 100% of structs can be `ResolvedValue`, because structs using these fields cannot otherwise be ported over to `ResolvedVc`. ## Okay, but Why? Explained here: vercel/turborepo#8843 (comment) I expect removing support for this will decrease the overall size of the codebase, as the logic for supporting generics is rather complicated.
Description
all_in_one
so that we can see exactly which parts are failing more easily.test_read_ref_round_trip
fails (and is ignored), indicating a bug in the generics implementation!!! This is fixed in FixReadRef<T>::cell
whenT
!=T::Read::Repr
#8845.Why does
test_read_ref_round_trip
fail?The theory is that Vcs are supposed to be stored as
<<T as VcValueType>::Read as VcRead<T>>::Repr
. However, it looks like due to an oversight,ReadRef::cell
is trying to store the value asT
.Why add these tests at all?
The plan (as of yesterday) is to remove support for generics, but I'd feel more confident if I can fix the casting issues in my local Vc PRs before I do that.
These tests should help me understand what's happening and debug things.
Testing Instructions